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In order to function effectively, a network needs to enforce 
and provide proper models for network security. One spe- 
cific aspect of network security, related to network, is access 
protection. In this chapter, we examine the challenges asso- 
ciated with protecting access to a computer network and the 
different approaches that can be used to address the various 
threats to a network. This chapter provides a review of com- 
mon types of access control models, adversary models for 
network access control, and the methods commonly used to 
provide network access protection. 

INTRODUCTION 

Network access protection is the task of ensuring that the net- 
work is protected against unauthorized access. This includes 
preventing unwanted parties from accessing the services and 
applications running on the network. The unwanted parties 
may be external or internal to the network. Protecting the 
access to the network requires specific mechanisms, proto- 
cols, and approaches. In this chapter, we provide information 
on various approaches that can be used to protect the access 
to a network. 

The networks that we will examine deeply are ones based 
on the Internet Protocol or IP. This covers the networks 
such as the global Internet as well as the various corporate 
intranets that are designed using the Internet Protocol. In 
industrial environments, one may find networks based on 
other protocols. In particular, many sensor and actuator net- 
works used in industrial settings are not based on the IP pro- 
tocol. However, the general approaches for network access 
protection will be somewhat similar. 

The first part of this chapter has a discussion of mod- 
els for access protection or access control. The access con- 
trol models provide a way to specify who has the ability to 
access a resource, and who does not. The models for network 
access control are a specialization of this general approach 
for access control, when the resource is the network. 

Following the general description of the access control 
models, we examine the different types of threats from unau- 
thorized entries that may be attempting to illegally access 
the network. Such threats may come from outside the net- 
work, as well as from adversaries that are located inside the 
network. 


ACCESS PROTECTION MODELS 

General models for functionality in computer science are 
usually given in terms of simplified abstractions, an abstrac- 
tion being the simplified representation of an idealized entity. 
For access protection, two different abstractions are usually 
used: the abstraction of a resource and the abstraction of a 
user. A resource is any entity that is accessed by other enti- 
ties. The entities that are trying to access the resources are 
called users. A resource allows some operations to be per- 
formed upon it by the users, for example, a user could access 
the resource without making any changes, make changes 
to the resource, delete an existing resource, or create a new 
resource. 

In the case of a computer network, the resource could be 
a computer within the network and the user could be the indi- 
vidual trying to use the computer. Alternatively, the resource 
could be the network infrastructure and the user could be a 
computer that is being connected to the network infrastruc- 
ture. In another case, the resource could be a particular por- 
tion of the subnet (e.g., a set of servers running on a specific 
segment of the network) and the user could be the client com- 
puter trying to access those servers. 

Access protection is the task of defining which set of 
users is allowed to access a specific resource. Access protec- 
tion models provide an overall approach on defining access 
protection. In the next few subsections, we examine some of 
the commonly used access protection models opted by the 
networking community. 

Bell Padula Model 

The Bell Padula model was initially proposed for military 
access control purposes, but the conceptual abstractions pro- 
posed in the model are applicable for access protection in 
general. In the Bell Padula model, all resources are assigned 
a label describing the access restriction. 

An example of a “labels” system may be the use of three 
labels called Unclassified, Secret, and Top Secret. A total 
ordering is defined among all the labels, and in the above 
example the ordering would be Unclassified < Secret < Top 
Secret. The same labels are also assigned to the users to 
denote the clearance level that the user may have. In the 
Bell Padula model, a user with a specific label for clearance 
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FIG. 35.1 

Bell Padula model. 

level is allowed to access all resources that have an access 
restriction label lower that its clearance level. Thus, a user 
with the label of secret is allowed to access any resource with 
a label of unclassified or secret. 

The Bell Padula model is illustrated in Figure 35.1. The 
levels of increasing security are shown as horizontal bands. 
All users and resources are assigned to one of these bands. 
As long as a user is in a higher band than the resource, the 
user is allowed to access that resource and perform any of 
the specific operations on the resource. Any user can access 
a resource that is at a level below its own security level. Thus, 
access shown by arrow A and B is allowed, while the access 
shown by arrow C is disallowed. 

The Bell Padula model has been used for controlling 
access in many computer operating systems. The Multics 
operating system, for example, used a system of increasing 
levels of security protection, and the current access control 
distinction in Unix and its variants of programs existing with 
root privileges and user privileges are some examples of its 
usage in computer systems. 
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Access control lists. 

1 includes users A and C, that for resource 2 includes users B 
and C, while that for resource 3 only includes user B. 

Access control lists are frequently used to control access 
in network using special devices such as firewalls. A resource 
in this context is an application running on the network iden- 
tified by its network address and port, and users are identified 
by their network address. The access control lists enumerate 
which sets of users are allowed to access a specific resource. 
Another use of access control lists is in controlling the access 
to files stored within a computer. 

Capabilities 

A capability enumerates all the resources that a user is 
allowed to access. This list is associated with a user. Since 
a resource may allow different types of operations to it, the 
capability would also define the operation the user is allowed 
to perform on the resource. 

In Figure 35.3, the capability of the user A is the abil- 
ity to access resource 1, the capability of user B is to access 
resources 2 and 3, while user C has capability to access 
resources 1 and 2. 

A capability can be viewed as a complementary approach 
to specify the access control matrix to access control lists. 


Access Control Lists 

An access control list enumerates all the users that are 
allowed to access a resource. This list is associated with a 
resource. Since a resource may allow different types of oper- 
ations to it, the access control list associated with different 
operations may be different. 

If we make a matrix with users enumerated along the 
vertical axis and resources enumerated along the horizontal 
axis, we could create an entry of “Yes” or “No” for each entry 
within the table, depending on whether the specified user is 
allowed to access the resource or not for a specific operation. 
The access control list is an enumeration of this access control 
matrix along its columns. This model for access control lists 
is shown in Figure 35.2. The access control lists for resource 
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While the access control list enumerates the columns of the 
matrix, the capability enumerates the rows of the matrix for 
any specific operation. 

Role-Based Access Control 

In a practical environment, the use of access control matrix is 
not feasible as a complete enumeration since there are a large 
number of users and resources. The explicit enumeration of 
the entries of an access control matrix can grow rapidly very 
large. Role -based access control is a method to reduce the 
complexity of expressing the access control lists. 

In role -based access control, the users are defined into 
multiple groups, each group having an assigned role. The 
mapping of users to roles need not be exclusive and a user 
could have more than one role. Instead of specifying access 
control lists (or capabilities) in terms of users trying to access 
a resource, they are expressed in terms of a specific role try- 
ing to access a role. 

Role -based access control allows a more flexible and 
compact representation of access control lists. Multiple users 
can be assigned into the same role, and some users may be 
assigned to more than one role, allowing a much more flex- 
ible and concise approach to specify the resource. As an 
example, let us consider a small enterprise that consists of 
about a hundred employees, divided into different depart- 
ments. The enterprise has a customer database, product plan 
database, and personnel database. The enterprise can define 
three roles for access to the database, for example, people can 
be classified into technical, marketing, and administrative 
roles, and role-based access control can be made as follow- 
ing. The technical role is allowed to access the product plan 
database, while marketing is allowed to access both product 
and customer databases. An administrative role is allowed to 
access the personnel database. The assignment of a person to 
specific roles can be made depending on their responsibilities, 
regardless of which department of the enterprise they work in. 

Role -based access control allows the specification of 
access in terms of a few roles, instead of enumerating them 
for all the users, and also allows more flexibility by allowing 
a user to have more than one role. 

Resource Hierarchy 

Just like “defining roles” allows one to reduce the number 
of access control lists that have to be maintained for a large 
number of users, techniques need to be developed to man- 
age a large number of resources. A hierarchical approach is 
often used to reduce the number of resources that need to be 
explicitly called out for specifying access control. 

A common method to make the number of resources 
manageable is to define a hierarchy, which is a tree structure. 
The access control restrictions that are specified for a node 
in the tree are valid for all elements that are children of the 
node, unless the access control is explicitly overridden by one 
of the child nodes. 



FIG. 35.4 

Resource hierarchy. 


Figure 35.4 shows an example of a resource hierarchy 
where the resources names are arranged in a hierarchical 
manner, for example, the URLs (Uniform Resource Locator) 
of a webpage. The resource hierarchy is used to show access 
control rights for a specific user, who is allowed to use any 
resource with a URL beginning with the prefix/pages, not 
allowed to access resources under the prefix/pages/data, 
except the resource/pages/data/public. 


Policy-Based Access Control 

A general way to specify access control is provided using 
policy based access controls. A policy-based access control 
specifies access controls by writing a set of policies, a policy 
being a specification stating the conditions under which a 
user has an access to a resource. The policy-based frame- 
work is more general than the previously defined access con- 
trol frameworks in that it can allow a specification of access 
control that must be enforced and are obligatory, as well as 
“access” control that can possibly be provided in a discretion- 
ary optional manner. 

A policy is an expression of access control in terms of a 
condition and an action. The condition is any logical combi- 
nation of the attributes of the user and the resource, plus any 
other set of conditions that can be defined, for example, time 
of day, a specific condition being true in the environment, or 
a function computed over some other variables that can be 
measured in the environment. This permits a greater degree 
of flexibility in specifying access control. 

As an example, a policy may state that all operators in a 
process plant are allowed to access their server containing 
information on process performance and material flow at all 
times, except for the last 2 days when the server can only be 
accessed by maintenance department. Other types of condi- 
tions may include the history of a user, for example, an opera- 
tor who has access to information for one set of machines 
may not be allowed to access information on another set. 

The use of policies for access control is found in many 
current computer software systems, although the exact 
format for policies are quite variable. Some standards have 
emerged to specify access control, for example, XACML 
(extensible Access Control Markup Language) or the OASIS 
(Organization for the Advancement of Structured Information 
Standards) extended access control mark-up language 
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provides a standard way to specify access control policies 
in XML (Extensible Markup Language), and CIM-SPL 
(Common Information Model — Simple Policy Language). 

NETWORK ACCESS PROTECTION 

Having examined some of the models by which the access 
control restrictions are specified, let us examine the architec- 
tural model by which network access protection is provided. 
The goal of network access protection is to enable the “net- 
work access control restrictions” to be specified and enforced 
within a network. We would specify the network access pro- 
tection architecture as an abstract specification, that is, in 
terms of functions that need to be performed. In different 
environments, different variations of the architecture would 
be combined into various components. After presenting the 
abstract architecture, we would examine how instances of 
the architecture are realized in specific environments. In the 
context of a control network, the abstract network access con- 
trol architecture would need to be implemented in a similar 
manner. 

Generic Access Protection Architecture 

The generic architecture for access protection is shown in 
Figure 35.5. The generic architecture shows the different 
functions that are required in order to address the different 
aspects of implementing network access protection in a spe- 
cific network environment. The two basic abstractions in this 
generic architecture are the user and the resource. The user 
wants to access the resource. 

The different abstract entities shown in this figure are the 
user agent, the network access controller, the network access 
manager, the access policy repository, and the access policy 


editor. Other than the user, these abstract entities are within 
the administrative control of the organization that owns the 
resource or the network. 

The user agent is an entity whose task is to validate the 
attribute and properties of the user. This agent could be real- 
ized as a part of trusted software that is provided by the 
organization that owns the resource being accessed. As an 
example, if the user is a laptop that is trying to connect to a 
network, the user agent could be a piece of software running 
on the laptop that collects any credentials and attributes of 
the user and transmits them out for controlling access. 

The network access controller is an entity that is respon- 
sible for enforcing the access made to network resources. It is 
the entity that acts as the intermediary for all accesses made 
by any user to the resource and examines those requests to 
validate their ability to access the network resource. The net- 
work access controller has two main functions to perform: 
(1) validate that the user trying to access the resource is who 
it claims to be and (2) decide whether or not to grant access to 
that user for any resource. The former task is called authen- 
tication, and the latter is access control. Here, we do not 
examine the issues involved in authentication (more infor- 
mation is available in Chapters 29 and 30, and assume that 
the user is authenticated in some manner. Although the focus 
of this chapter is on access control, it is worth remembering 
that authentication is a key ingredient of properly managing 
access controls. In any network of reasonable size, there will 
be many instances of network access controllers. The access 
controllers in a network may be realized as a firewall, secu- 
rity gateways, or application-specific proxies depending on 
the network environment. 

When a request of a user to access a resource is received 
by the network access controller, it contacts a network access 
manager. The network access manager checks the identity of 
the user, the resource it wants to access, and then determines 



FIG. 35.5 

Generic network access protection architecture. 
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whether or not the access ought to be provided. In other 
words, the network access manager is responsible for decid- 
ing whether or not the access requested by the user is pro- 
vided, and it provides the “brains” for the network access 
controller. 

In the generic architecture, the roles of the network 
access controller and network access manager are called out 
separately. Depending on the environment of the network in 
which access protection is being provided, these two roles 
may be integrated into a single device. On the other hand, 
it is quite common in many large-scale networks to imple- 
ment these two entities separately. This allows the network 
access controller to be distributed at many points where users 
may be trying to access the network, while allowing their 
access control decisions to be centralized. As an example, let 
us consider an instance of an Internet Service Provider (ISP) 
where new users are trying to connect to the network. The 
network access controller is needed at every location where 
the user home router can be trying to connect to the ISP net- 
work. However, validation of the access is done at a small 
number of more secure places where network access manag- 
ers are running. In such an environment, standard protocols 
have been developed for the interaction between the access 
controller and the access managers — the most prominent of 
them being RADIUS, DIAMETER, and TAKACS. 

The network access manager usually makes its decisions 
on the basis of access control policies that may be represented 
using any one of the models described earlier. These policies 
are stored in a policy repository. In many types of practical 
instances, the policy repository is a directory that is accessed 
using the LDAP (Lightweight Directory Access Protocol). 

The last entity in the generic architecture is a tool that is 
used by an administrator to define the policies/access con- 
trol restrictions that ought to be enforced in the environment. 
This tool is usually used by the network security administra- 
tors at the network operations center. 

In the next sections, we examine two specific architec- 
tures for network access protection and describe how the 
generic architecture is obtained in these environments. 

Example Instance: Network Access Control 

One specific instance of the architecture can be seen in 
Figure 35.6 for the Network Access Control model supported 
in the IP networks. The specific context here is that of an 
enterprise where several users with their laptops connect to 
the enterprise network. Security on such networks is regu- 
lated by various protocols, and it is common to use a protocol 
like LEAP with a specific user-id and password for each user. 
In order to authenticate the different users and allow them to 
connect, the validation of the user-id and associated creden- 
tials is not done directly at the access point, but forwarded 
to an Access Control System (ACS). The ACS talks to the 
access point using a protocol like RADIUS. The ACS obtains 
the policies required for validating the users from a policy 
repository and determines who is allowed into the network. 



FIG. 35.6 

Network access control in an enterprise. 

The ACS obtains the policies for validating the users by 
using Role -Based Access Control (RBAC) policies that are 
stored in an LDAP Server. A large enterprise may choose 
to divide its network infrastructure into several independent 
ones, for example, different VLANs (Virtual Local Area 
Network), and a user is only allowed to have access to one of 
the VLANs. As an example, guests may be allowed to access 
only one VLAN, and other users may be mapped on to other 
VLANs. The enterprises that want to restrict access to spe- 
cific parts of their network depending on the responsibility of 
the employee may use role-based access control to determine 
which VLAN a user is mapped onto. This determination is 
made by the ACS. Actual mapping of data packets to the 
right VLAN is done by the access point. 

Other than the user agent, the entities in the generic archi- 
tecture can be readily mapped onto the functions performed 
by the servers in this specific instance of the architecture. 

Example Instance: NAP in VISTA 

Another instance of the generic architecture can be found in 
the Network Access Protection system that is implemented 
in the Microsoft Windows VISTA system. In this particular 
instance, a user agent is included with the laptops and per- 
sonal computers that are running a Windows Vista Operating 
System. The user agent is responsible for monitoring the 
health of the computer, for example, checking for absence 
of any malware or virus. The system health is reported to a 
health registration server. When the computer tries to con- 
nect to the network, for example, by trying to obtain access to 
the network through a DHCP (Dynamic Host Configuration 
Protocol) Server, the user agent needs to report the current 
health of the computer to the Health Registration Server. The 
Health Registration Server checks for compliance with a set 
of policy servers. In addition to the registration server and 
the policy server, the user agent may also need to access a 
network health requirement server, which provides informa- 
tion about malware or viruses that need to be checked on the 
computer accessing the network. 
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Until the health of the computer system is verified, the 
computer may not be allowed full access to the network, for 
example, it may be restricted to access only a subset of the 
network. Full access to the network is only permitted after 
the health of the computer is verified. The control or mapping 
of the computer to the specific network can be controlled by 
the assignment of the address by the DFICP server. 

There are other alternative ways to manage network 
access protection using the VISTA system, including: using 
it in conjunction with the network access control system 
described above, using VLANs for managing access, and 
mechanisms whereby machines found to be unhealthy are 
automatically put into a quarantined portion of the network. 

The VISTA NAP architecture can be seen as an instance 
of the generic architecture, where the user agent has a visible 
role, and the policy server functions augmented with other 
functions (e.g., health requirement server). 

CONCLUSIONS AND COMMENTS 

In this chapter, we have reviewed the general architecture of a 
network access protection system and seen specific instances 
of how that architecture for access protection is implemented 
in the computer networks in an enterprise. A similar instan- 
tiation can be made in the context of any control system that 
one is designing. The basic components of the general archi- 
tecture are reusable in any type of network. We also examined 
the different ways in which access protection restrictions can 
be specified, ranging from the use of simple levels of access 
protection to more flexible specification of complex access 
protection policies. Depending on the perceived threats of 
the network under design, one of the above models can be 
used to enforce network access protection. 
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